HCX による SDDC 間のL2延伸および仮想マシンの移行を試してみた
大家好，AWS事業本部の西野です。
VMware Cloud on AWS の SDDC 間で HCX による Network Extension と仮想マシンの移行を試してみました。
前提条件
各種の設定をする前の概要図がこちらです。
- 東京と大阪にそれぞれ VMware Cloud on AWS が存在している
- Classmethod-Tokyo (ap-northeast-1)
- Classmethod-Osaka (ap-northeast-3)
- 上記の SDDC は同じ SDDC グループのメンバーになっている
- Osaka 側にはあらかじめ仮想マシン用のセグメントと仮想マシンを作成済み
- セグメント
- xiyegen-osaka-network (192.168.150.0/24)
- 仮想マシン
- ubuntu-osaka（pingでubuntu-hcxを監視するための仮想マシン）
- ubuntu-hcx（移行対象マシン）
- セグメント
最終的な構成の概要図が以下のとおりです。
この構成を目指し設定を進めていきます。
HCX のデプロイ
まずは Tokyo 側の SDDC に HCX をデプロイしていきます。
VMware Cloud on AWS のコンソールからインベントリを開き、デプロイ対象の SDDC をクリックします。
統合サービスのタブをクリックした後、「HCX を開く」をクリックします。
デプロイ対象の SDDC 下部にある「DEPLOY HCX」をクリックします。
対象の SDDC が正しいか確認した後、 「CONFIRM」をクリックします。
Deployment Initiated のメッセージが表示されたら「CLOSE」をクリックします。
「VIEW DETAILS」をクリックするとデプロイの進捗状況を確認できます。
デプロイ完了後に vSphere Client から確認してみた様子です。hcx_cloud_manager が Mgmt-ResourcePool に追加されています。
SDDC への HCX デプロイそのものはこれだけの作業で完了です。
同様の作業を Osaka 側でも繰り返します。
ファイアウォールルールの設定
続いて、HCX を利用するために必要なファイアウォールルールを設定します。
VMC コンソール → インベントリ → ネットワークとセキュリティ → ゲートウェイファイアウォール → 管理ゲートウェイ の画面から以下のファイアウォールルールを設定してください。
| 名前（例） | 送信元 | 宛先 | サービス | 備考 |
|---|---|---|---|---|
| HCX inbound operator | 作業者のIPアドレス | HCX | HTTPS | |
| HCX inbound | 対向となる HCX が用いる IP アドレス | HCX | HTTPS | 今回はTokyo・Osakaの SDDC 間を接続するため、送信元として、Osaka 側ではTokyo 側 HCX のパブリック IP を、Tokyo 側では Osaka 側 HCX のパブリック IP を設定します。 |
| HCX outbound | HCX | 任意 | 任意 | VMware Cloud on AWS の SDDC 間でペアを作成する場合に必要 |
同様の作業を Osaka 側でも繰り返します。
HCX コンソールへの接続
ファイアウォールルールの設定を終えたら HCX コンソールへの接続を試してみます。
統合サービスのタブから「HCX を開く」をクリックします。
「OPEN HCX」をクリックします。
ファイアウォールルールが正しく設定されている場合、HCX のログイン画面にアクセスできます。
ユーザー名・パスワードを入力しログインします。このユーザー名・パスワードは vCenter Server のものと同一です。
ログインに成功すると HCX のダッシュボード画面が表示されます。
同様の確認を Osaka 側でも実施します。
Site Pairing の追加
Tokyo 側の HCX にログインし、Infrastructure → Site Pairing から「CONNECT TO REMOTE SITE」をクリックします。
Remote HCX URL として Osaka 側 HCX の URL を入力します。Username および Password には Osaka 側 vCenter Server のものを入力し接続します。
無事接続が完了すると Site Pairing の画面にこのように表示がされます。続いて、逆方向（Osaka → Tokyo）でも同じ作業をします。
逆方向からの Site Pairing が接続されると矢印マークが双方向のものに変化します。
HCX Service Mesh の作成
続いて HCX の Service Mesh を作成していきます。
この Service Mesh の作成により実際に仮想マシンの移行や L2 延伸を担う仮想アプライアンスが別途デプロイされます。
Osaka 側の HCX にログインし、Infrastructure → Interconnect から「CREATE SERVICE MESH」をクリックします。
サイトのペアが正しいことを確認した後「CONTINUE」をクリックします。
Source と Remote でそれぞれ Compute Profile を設定します。ここではデフォルトで存在する ComputeProfile(vcenter) を選択し、「CONTINUE」をクリックします。
HCX で用いる必要な機能を選択し「CONTINUE」をクリックします。
（本稿の検証ですべて機能を利用するわけではありませんが、ここではデフォルトのままとします。）
Advanced Configuration - Override Uplink Network profiles の画面でも特に何も設定せずに「CONTINUE」をクリックします。
Advanced Configuration - Network Extension Applicance Scale Out の画面でも特に何も設定せずに「CONTINUE」をクリックします。
Advanced Configuration - Traffic Engineering の画面でも特に何も設定せずに「CONTINUE」をクリックします。
Review Topology Preview の画面では導入されるコンポーネントやネットワークの構成をプレビューできます。「CONTINUE」をクリックします。
Service Mesh に任意の名称を付与し、「FINISH」をクリックします。
そのまましばらく経過すると Service Mesh の作成が完了します。
Network Extension の作成
Osaka 側の HCX にログインし、Services → Network Extension から「CREATE A NETWORK EXTENSION」をクリックします。
ネットワーク一覧の中から延伸したいネットワークを選択し「NEXT」をクリックします。
Gateway IP Address に延伸元ネットワークの Gateway IP Address を入力し、「SUBMIT」をクリックします。
しばらくすると Network Extension が作成されます。
マイグレーションの実行
Osaka 側の HCX にログインし、Services → Migration から「MIGRATE」をクリックします。
Source と Destination のペアを正しく選択した後、移行対象の仮想マシン（ubuntu-hcx）を指定します。
また、移行対象の仮想マシンが Destination（つまり Tokyo 側 SDDC）で用いるリソースプール・データストアや移行方式を選択します。今回は移行方式として vMotion を利用します。
続いて「VALIDATE」をクリックし設定内容を検証します。問題がなければ「GO」をクリックすると移行が開始されます。
マイグレーションの途中経過をこの画面から確認できます。
Osaka 側の仮想マシン ubuntu-osaka から ubuntu-hcx（移行対象）に ping を実行していた様子がこちらです。ほぼ途切れることなく疎通できていることが見て取れます。
HCX の画面からも移行が完了していることを確認できます。
参考ドキュメント
Deploying HCX from the VMware Cloud on AWS Console
【小ネタ】HCXのサービスメッシュ作成時に特定のサービスのみActivateする - Qiita
終わりに
今回の検証を経て、やはり VMware Cloud on AWS の「マネージド」感はすばらしいなと改めて感じています。オンプレミス環境だと構築にそれなりに骨が折れそうな環境がボタン一つでサクサクできあがっていきます。
今回パラメーターをデフォルトのままにした部分については今後のブログでもう少し掘り下げていくつもりです。
このブログがほんの少しでも世界を良くできれば嬉しいです。
AWS事業本部の西野 (@xiyegen) がお送りしました。
